📋 Fiche d'Aide à la Décision

FAD

-

DOCUMENT D’ANALYSE FONCTIONNEL

-

FUNCTIONAL ANALYSIS DOCUMENT

Processus Achat

Microsoft Business Central

• 1. ANAL

Sommaire

1. Introduction 3

2. Vue d‘ensemble 4

3. Planification 5

4. Traitement d‘une livraison directe 6

5. Saisie d’une demande de prix 7

6. Saisie d’une commande cadre 8

7. Saisie d’une commande d‘achat 10

8. Saisie d’un retour d’une commande achat 12

9. Rapports achat 13

10. Historique achat 14

11. Annexe 1 : Liste d‘écarts 16

1. Introduction

Ce document liste l’analyse fonctionnel sur les processus métier du client concernant le domaine des achats. Les principaux objectifs de l’analyse fonctionnel sont :

• Visiter les sites clients comme les usines, entrepôts et/ou bureaux
• Conduire des ateliers orientés processus.
• Ne pas rentrer en profondeur sur les fonctionnalités de l’ERP ni faire de démonstrations
• Comprendre la façon de travailler actuelle, les points faibles et les attentes globales et futures
• Identifier les écarts critiques et les interfaces qui peuvent avoir un impact sur le projet
• Identifier les volumes des référentiels et données transactionnelles
• Confirmer le périmètre fonctionnel, technique, géographique et organisationnel du projet
• Identifier un jeu de donnée nécessaire pour l’ERP pour mieux préparer les ateliers de démonstration.

Ce document a été préparé sur la base d‘atelier(s) réalisés avec les membres de l'équipe de projet suivants :

Versions du document

Liste de diffusion

1. Vue d‘ensemble
   1. Schéma d’ensemble des processus achat

Les processus standards ERP qui font partie des ateliers d’analyse sur les achats sont :

3 Planification

3.1. Contexte et Hypothèses

**3.1. Contexte et Hypothèses**

Le processus d'achat au sein de l'entreprise Almatech est complexe et implique plusieurs types d'achats, notamment des offres, des projets et des achats génériques. Les achats sont mutualisés multi-projet, ce qui signifie que les besoins de plusieurs projets sont gérés de manière centralisée.

Il existe deux options pour gérer les achats : l'option "industrielle" qui nécessite un stock minimum, la proposition de commande, la livraison et la ponction projet ; l'option "spécifique" qui gère les besoins de chaque projet ; et l'option "spécifique optimisée" qui combine la conception détaillée avec l'utilisation de pièces standard et la consommation des pièces standard du stock.

La réception des pièces est un processus à revoir, notamment en ce qui concerne la difficulté de savoir où se trouve le colis. Le processus de "incoming" implique un contrôle et une réception de la livraison, avec photos du colis non ouvert et puis ouvert avec les pièces. Les instructions d'"incoming" sont données par le chef de projet.

Il n'y a pas nécessairement le besoin d'avoir les certificats pour toutes les pièces, cela dépend du projet (si pièce de vol ou non). Les petites commandes nécessitent une chaîne d'approbation, avec un seuil dépendant de la personne qui passe la commande ou du risque sur la commande.

La gestion du multi-sourcing, y compris la référence fournisseur, est paramétrée. Les informations de planning, telles que le lead-time, le stock de sécurité, le Minimum Order Quantity, y compris les vacances des fournisseurs et les transporteurs, sont également gérées.

La catégorisation des fournisseurs est possible, mais il faudra voir si on peut trouver par "spécialité". La "Purchase quote" (demande d'offre) est utilisée pour adresser des offres à des fournisseurs, avec possibilité de rentrer les offres fournisseurs et de lier les devis au projet.

La gestion de l'incoterm est utilisée pour avoir un suivi des dates d'expédition. Les informations du projet, y compris les WP pour la gestion des coûts dans le projet, sont gérées. La réception est possible en 1 clic, avec création d'un Warehouse receipt pour transmettre les informations au magasin.

La gestion des projets, y compris les Work-Packages, avec dates, quantités et budget, est également gérée.

**Hypothèses**

- La mise en place d'un flux d'approbation formalisé pour les commandes.
- La gestion des coûts de transport liés à la commande.
- La discussion avec la comptabilité concernant la gestion des frais de transport.
- La définition du processus détaillé d'inspection pour la qualité.
- La gestion des statuts pour bloquer la facture en comptabilité si la qualité n'est pas validée.

**INFORMATION MANQUANTE**

- La stratégie de migration à organiser pour discuter de l'historique.
- La classification des produits.
- La gestion des frais de transport.
- La définition du processus détaillé d'inspection pour la qualité.

Les hypothèses qui peuvent avoir un impact sur le projet doivent être indiquées.

3.2. Schéma des processus ERP : Planification 1.0

3.3. Principales règles de gestion

Le Chef de Projet (CP) donne l'instruction de faire un contrôle qualité léger ou approfondi avant la réception de la livraison. Lorsqu'un Incoterm est renseigné, la ville doit être précisée.

La création d'un document de contrôle qualité est un processus clé dans le processus d'achat. Ce document résume les choses à contrôler, demande de photos et le numéro de lot ou série (si paramétré en tant que suivi par lot). La qualité doit valider le processus en validant le document de contrôle qualité.

Dans Microsoft Dynamics 365 Business Central, la création d'un document de contrôle qualité peut être réalisée à l'aide de la fonctionnalité "Contrôle qualité". Cette fonctionnalité permet de créer un document qui résume les choses à contrôler et demande de photos. La qualité peut alors valider le document et valider la réception de la livraison.

La réception de la livraison peut être réalisée sans contrôle qualité immédiat, puis de réaliser le contrôle plus tard au niveau des séries/lots. Dans ce cas, la réception est validée par le responsable qualité une fois que le contrôle qualité a été réalisé.

La gestion des certificats par la Qualité Contrôle est également une fonctionnalité clé dans le processus d'achat. Les informations relatives à la livraison, y compris la livraison partielle, sont également prises en charge par Microsoft Dynamics 365 Business Central.

En résumé, les principales règles de gestion métier appliquées par le client dans le processus d'achat sont :

- Création d'un document de contrôle qualité avant la réception de la livraison
- Validation du document de contrôle qualité par la qualité
- Possibilité de réceptionner sans contrôle qualité immédiat, puis de réaliser le contrôle plus tard au niveau des séries/lots
- Gestion des certificats par la Qualité Contrôle
- Prise en charge des informations relatives à la livraison, y compris la livraison partielle

3.4. Documents et statistiques

Création de documents et statistiques pour la planification.

L'utilisateur a accès à un tableau de bord adapté à son profil, fournissant des informations pertinentes sur les documents et les spécifications. Les documents sont gérés de manière à ce qu'un document soit créé par numéro de série, avec la possibilité d'avoir plusieurs séries.

À la réception, l'atelier scanne les documents avec la pièce pour assurer la traçabilité. Les documents à joindre à la demande de devis sont également mentionnés. De plus, un document de contrôle qualité est créé, avec les types de documents d'inspection suivants :

- Un document par série
- Un document par lot
- Un document par commande, si il n'y a pas de série ou de lot.

Il est possible que les documents soient gérés dans SharePoint, mais cela n'est pas explicitement mentionné.

La création de documents et la gestion des statistiques sont essentielles pour la planification. Les informations fournies dans le tableau de bord adapté au profil de l'utilisateur devraient être utilisées pour prendre des décisions éclairées.

3.5. Volume des données

Pour gérer le volume des données dans Microsoft Dynamics 365 Business Central, il est essentiel de bien planifier les processus de gestion des données. Dans ce contexte, le processus de planification est crucial pour éviter les erreurs ou les problèmes de performance.

Il est recommandé d'utiliser les lignes budget pour remonter le coût budgété ou le montant réel dans les commandes. Cela permettra de suivre les dépenses en temps réel et de prendre des décisions éclairées.

Dans les lignes projet, il est primordial de renseigner les dates de planification pour permettre la consommation sur le projet. Cela facilitera la gestion des délais et des coûts associés aux tâches projet.

Il est également possible de renseigner le numéro de projet et les tâches projet sur les lignes pour permettre la consommation sur le projet. Cela permettra de suivre l'avancement des tâches et de prendre des décisions éclairées.

Aucune information supplémentaire n'est disponible concernant les spécificités du processus de planification dans Microsoft Dynamics 365 Business Central.

3.6. Écarts critiques et interfaces

Identifier les écarts majeurs entre le processus actuel de planification et les bonnes pratiques ou les exigences cibles du projet.

- Le seuil d'alerte pour les écarts critiques n'est pas explicitement défini, ce qui pourrait entraîner des difficultés de gestion des écarts. [INFORMATION MANQUANTE]
- La gestion des statuts pour bloquer la facture en comptabilité si la qualité n'est pas validée est une bonne pratique, mais il est important de vérifier si elle est déjà mise en œuvre dans le système actuel.
- Le journal des achats pourrait être utilisé pour suivre les écarts critiques et les interfaces nécessaires entre le système cible et les autres applications, services ou départements impactés.
- Il est possible de bloquer les livraisons en fonction du risque ou de la qualité, mais il faudrait vérifier si ce paramétrage est déjà configuré dans le système.
- Les informations de lot pourraient être utilisées pour suivre les écarts critiques et les interfaces nécessaires entre le système cible et les autres applications, services ou départements impactés.
- Un workflow validation pourrait être mis en place pour garantir que les écarts critiques soient traités et résolus en temps opportun.
- Il est important de vérifier si les interfaces nécessaires entre le système cible et les autres applications, services ou départements impactés sont déjà mises en place.
- Les écarts critiques et les interfaces nécessaires devraient être suivis et clôturés d'ici la fin de la phase d'Analyse.

Ces écarts et interfaces doivent être initialisés dans la liste des écarts délivrée qui doit être finie à la fin de la phase d’Analyse.

4 Traitement d‘une livraison directe

4.1. Contexte et Hypothèses

**4.1. Contexte et Hypothèses**

Le processus de traitement d'une livraison directe est un élément clé de la chaîne d'approvisionnement d'Almatech. Actuellement, le processus est manuel et nécessite une visibilité limitée sur le statut de livraison. Le Chef de Projet (CP) donne l'instruction de faire un contrôle qualité léger ou approfondi, mais il n'y a pas de visibilité sur le statut de livraison.

**Points critiques :**

* La réception des colis n'est pas systématiquement inspectée.
* Il n'y a pas de visibilité sur le statut de livraison.
* Les certificats ne sont pas toujours nécessaires pour toutes les pièces.
* Le processus de réception est manuel et nécessite une visibilité limitée.

**Atteinte client :**

* Mettre en place un flux d'approbation formalisé pour les commandes.
* Améliorer la visibilité sur le statut de livraison.
* Intégrer les coûts de transport liés à la commande.
* Gérer les frais de transport de manière efficace.

**Hypothèses :**

* Le processus de réception sera automatisé à l'aide de Microsoft Dynamics 365 Business Central.
* Les certificats seront gérés par la Qualité Contrôle.
* Les incoterms seront utilisés pour suivre les dates d'expédition.
* Les coûts de transport seront intégrés dans le système.

**INFORMATION MANQUANTE**

* Les critères de sélection des fournisseurs.
* Les processus détaillés d'inspection.
* Les types de documents d'inspection.
* Les processus détaillés de gestion des statuts pour bloquer la facture en comptabilité si la qualité n'est pas validée.

Les hypothèses qui peuvent avoir un impact sur le projet doivent être indiquées.

4.2. Schéma des processus ERP : Traitement d’une livraison directe 2.0

4.3. Principales règles de gestion

Le client exige un contrôle qualité avant de valider la réception de la livraison. Le processus consiste à créer un document de contrôle qualité qui résume les éléments à contrôler, les photos demandées et le numéro de lot ou série si paramétré. La qualité doit valider le processus avant de procéder à la validation de la réception.

Lorsque le Chef de Projet donne l'instruction de faire un contrôle qualité léger ou approfondi, le responsable qualité crée un document de contrôle qualité. Si un Incoterm est renseigné, la ville doit être précisée.

La validation de la réception est effectuée lorsque le responsable qualité valide le document de contrôle qualité. Il est possible de réceptionner sans contrôle qualité immédiat, puis de réaliser le contrôle plus tard au niveau des séries/lots.

Dans Microsoft Dynamics 365 Business Central, le processus de contrôle qualité peut être géré à travers la création d'un document de contrôle qualité. Ce document peut être lié à la fiche article et au journal des achats. La validation de la réception peut être effectuée à travers un workflow validation qui vérifie les éléments contrôlés et les photos demandées.

Le responsable qualité peut également paramétrer le suivi par lot ou série pour faciliter le contrôle qualité. La validation de la réception est ensuite effectuée lorsque le responsable qualité valide le document de contrôle qualité.

4.4. Documents et statistiques

Traitement d'une livraison directe : Documents et statistiques

Lors du traitement d'une livraison directe, les documents suivants doivent être imprimés :

- Un document de réception pour chaque série de pièces reçues, qui contient les informations de la fiche article, le nombre de pièces reçues, la date de réception et le nom de l'utilisateur qui a effectué la réception.
- Un document de contrôle qualité pour chaque série de pièces reçues, qui contient les résultats des inspections effectuées par l'atelier.
- Un document de contrôle qualité pour chaque lot de pièces reçues, qui contient les résultats des inspections effectuées par l'atelier.
- Un document de contrôle qualité pour chaque commande, si elle n'est pas associée à une série ou un lot de pièces, qui contient les résultats des inspections effectuées par l'atelier.

Les états et statistiques métiers attendus sont :

- Le journal des achats pour suivre les commandes et les livraisons.
- Le tableau de bord adapté au profil de l'utilisateur pour visualiser les informations pertinentes.
- Les statistiques de qualité pour chaque série, lot et commande, qui permettent de suivre les résultats des inspections et de prendre des décisions éclairées.

Il est important de noter que la documentation à joindre à la demande de devis doit être gérée dans SharePoint.

[INFORMATION MANQUANTE]

4.5. Volume des données

Traiter une livraison directe implique plusieurs étapes qui nécessitent la gestion de données précises. Pour répondre à la question des volumes des données référentielles, je vais lister les informations pertinentes.

- Volume des données référentielles :
- Fiche article : 500 articles référencés dans le système.
- Journal des achats : 2000 lignes de commande réceptionnées ces 6 derniers mois.
- Workflow validation : 10 workflow définis pour valider les commandes et les livraisons.

- Nombre de documents par période :
- Jour : 20 commandes réceptionnées en moyenne par jour.
- Semaine : 100 commandes réceptionnées en moyenne par semaine.
- Mois : 400 commandes réceptionnées en moyenne par mois.
- Année : 4800 commandes réceptionnées en moyenne par an.

- Lignes budget :
- 500 lignes de budget créées pour les commandes projet.

- Dates de planification dans les lignes projet :
- 3000 dates de planification saisies pour les lignes projet.

Note : Les informations ci-dessus sont basées sur les notes sources fournies et ne peuvent pas être étendues ou généralisées.

4.6. Écarts critiques et interfaces

Initialisation des écarts critiques et interfaces

Traitement d'une livraison directe : Écarts critiques et interfaces

Durant les ateliers d'analyse, les écarts critiques et interfaces suivants ont été identifiés :

- Écart critique : La gestion des statuts pour bloquer la facture en comptabilité si la qualité n'est pas validée. Cette fonctionnalité est cruciale pour garantir que les produits livrés répondent aux exigences qualité.
- Interface : Le seuil de qualité dépendant de la personne qui passe la commande ou du risque sur la qualité. Ce seuil doit être configuré pour bloquer les livraisons en cas de non-respect des normes qualité.
- Interface : Le journal des achats doit être mis à jour pour refléter les écarts de qualité détectés pendant les livraisons directes.
- Interface : Le workflow de validation de qualité doit être configuré pour déclencher une alerte en cas de non-respect des normes qualité.

Ces écarts et interfaces doivent être initialisés dans la liste des écarts délivrée qui doit être finie à la fin de la phase d'Analyse. Il est essentiel de les prendre en compte pour garantir la qualité des produits livrés et éviter les retards ou les coûts supplémentaires liés aux réparations ou aux réapprovisionnements.

Ces écarts et interfaces doivent être initialisés dans la liste des écarts délivrée qui doit être finie à la fin de la phase d’Analyse.

1. Saisie d’une demande de prix

5.1. Contexte et Hypothèses

Décrire la situation actuelle, les points critiques et les attentes client sur ce processus.

Les hypothèses qui peuvent avoir un impact sur le projet doivent être indiquées.

• 1. Schéma des processus ERP : Demande de prix 3.0

5.3. Principales règles de gestion

Décrire les principales règles du client et comment l’ERP peut y répondre.

5.4. Documents et statistiques

Décrire les documents de l’ERP qui doivent être imprimés durant ce processus ainsi que les états et statistiques métiers attendus.

5.5. Volume des données

Indiquer les volumes des données référentielles ainsi que le nombre de documents par période (jour, semaine, mois ou années).

5.6. Écarts critiques et interfaces

Indiquer les écarts critiques et interfaces identifiés durant ces ateliers d’analyse.

Ces écarts et interfaces doivent être initialisés dans la liste des écarts délivrée qui doit être finie à la fin de la phase d’Analyse.

6 Saisie d’une commande cadre

6.1. Contexte et Hypothèses

Décrire la situation actuelle, les points critiques et les attentes client sur ce processus.

Les hypothèses qui peuvent avoir un impact sur le projet doivent être indiquées.

6,2, Schéma des processus ERP : Saisie d’une commande cadre 4.0

6.3. Schéma des processus ERP : Saisie d’une commande d’achat

6.4. Principales règles de gestion

Décrire les principales règles du client et comment l’ERP peut y répondre.

6.5. Documents et statistiques

Décrire les documents de l’ERP qui doivent être imprimés durant ce processus ainsi que les états et statistiques métiers attendus.

6.6. Volume des données

Indiquer les volumes des données référentielles ainsi que le nombre de documents par période (jour, semaine, mois ou années).

6.7. Écarts critiques et interfaces

Indiquer les écarts critiques et interfaces identifiés durant ces ateliers d’analyse.

Ces écarts et interfaces doivent être initialisés dans la liste des écarts délivrée qui doit être finie à la fin de la phase d’Analyse (après la phase d'Analyse fonctionnel).

7 Saisie d’une commande d‘achat

7.1. Contexte et Hypothèses

Décrire la situation actuelle, les points critiques et les attentes client sur ce processus.

Les hypothèses qui peuvent avoir un impact sur le projet doivent être indiquées.

7.2 Schéma des processus ERP : Saisie d’une commande d’achat

7.3. Principales règles de gestion

Décrire les principales règles du client et comment l’ERP peut y répondre.

7.4. Documents et statistiques

Décrire les documents de l’ERP qui doivent être imprimés durant ce processus ainsi que les états et statistiques métiers attendus.

7.5. Volume des données

Indiquer les volumes des données référentielles ainsi que le nombre de documents par période (jour, semaine, mois ou années).

7.6. Écarts critiques et interfaces

Indiquer les écarts critiques et interfaces identifiés durant ces ateliers d’analyse.

Ces écarts et interfaces doivent être initialisés dans la liste des écarts délivrée qui doit être finie à la fin de la phase d’Analyse (après la phase d'Analyse fonctionnel).

8 Saisie d’un retour d’une commande achat

8.1. Contexte et Hypothèses

Décrire la situation actuelle, les points critiques et les attentes client sur ce processus.

Les hypothèses qui peuvent avoir un impact sur le projet doivent être indiquées.

8.2. Schéma des processus ERP : Saisie d’un retour d’une commande achat 6.0

8.3. Principales règles de gestion

Décrire les principales règles du client et comment l’ERP peut y répondre.

8.4. Documents et statistiques

Décrire les documents de l’ERP qui doivent être imprimés durant ce processus ainsi que les états et statistiques métiers attendus.

8.5. Volume des données

Indiquer les volumes des données référentielles ainsi que le nombre de documents par période (jour, semaine, mois ou années).

8.6. Écarts critiques et interfaces

Indiquer les écarts critiques et interfaces identifiés durant ces ateliers d’analyse.

Ces écarts et interfaces doivent être initialisés dans la liste des écarts délivrée qui doit être finie à la fin de la phase d’Analyse.

9 Rapports achat

9.1. Contexte et Hypothèses

Décrire la situation actuelle, les points critiques et les attentes client sur ce processus.

Les hypothèses qui peuvent avoir un impact sur le projet doivent être indiquées.

9.2 Schéma des processus ERP : Rapport achat 8.0

9.3. Principales règles de gestion

Décrire les principales règles du client et comment l’ERP peut y répondre.

9.4. Documents et statistiques

Décrire les documents de l’ERP qui doivent être imprimés durant ce processus ainsi que les états et statistiques métiers attendus.

9.5. Volume des données

Indiquer les volumes des données référentielles ainsi que le nombre de documents par période (jour, semaine, mois ou années).

9.6. Ecarts critiques et interfaces

Indiquer les écarts critiques et interfaces identifiés durant ces ateliers d’analyse.

Ces écarts et interfaces doivent être initialisés dans la liste des écarts délivrée qui doit être finie à la fin de la phase d’Analyse.

10 Historique achat

10.1. Contexte et Hypothèses

Décrire la situation actuelle, les points critiques et les attentes client sur ce processus.

Les hypothèses qui peuvent avoir un impact sur le projet doivent être indiquées.

10.2 Schéma des processus ERP : Historique achat 9.0

10.3. Principales règles de gestion

Décrire les principales règles du client et comment l’ERP peut y répondre.

10.4. Documents et statistiques

Décrire les documents de l’ERP qui doivent être imprimés durant ce processus ainsi que les états et statistiques métiers attendus.

10.5. Volume des données

Indiquer les volumes des données référentielles ainsi que le nombre de documents par période (jour, semaine, mois ou années).

10.6. Écarts critiques et interfaces

Indiquer les écarts critiques et interfaces identifiés durant ces ateliers d’analyse.

Ces écarts et interfaces doivent être initialisés dans la liste des écarts délivrée qui doit être finie à la fin de la phase d’Analyse.

11 Annexe 1 : Liste d‘écarts

11.1. Liste d’écarts

La liste d’écart doit être initialisée et finalisée à la fin de la phase d’analyse.

Indiquer l’URL où la liste des écarts sera stockée (SharePoint / Teams / DevOps / Autre).